-
-
Notifications
You must be signed in to change notification settings - Fork 618
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable code analysis via clang-tidy in Visual Studio #2187
Conversation
Signed-off-by: thecomputekid <[email protected]>
src/_premake_init.lua
Outdated
@@ -169,6 +169,12 @@ | |||
} | |||
} | |||
|
|||
api.register { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it seems visualstudio specific, put it in vstudio/_preload.lua instead.
Or maybe other generators "just" have to call clang-tidy source.cpp $(CXXFLAGS)
after cxx source.cpp $(CXXFLAGS)
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it seems visualstudio specific, put it in vstudio/_preload.lua instead.
This suggestion is easier, and something I have now added a commit for. Perhaps clang-tidy for other generators can be future work.
Signed-off-by: thecomputekid <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok for me
What does this PR do?
This PR enables the selection of clang-tidy as a code analyser when the code analyser action of Visual Studio is run in the IDE. Further details can be found in the official documentation.
How does this PR change Premake's behavior?
Add configuration-scoped option
clangtidy
for Visual Studio 2019 and above.I have tried to follow pre-existing conventions:
compilebuildoutputs
as an example.buildstlmodules
example, which was a similar boolean.Did you check all the boxes?
Focus on a single fix or feature; remove any unrelated formatting or code changes
Add unit tests showing fix or feature works; all tests pass
Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged)
Follow our coding conventions
Minimize the number of commits
Align documentation to your changes